> I knew somebody would ask, but answering it right along would have
 > made a long post even longer :-)

Well, with all your privious posts you gave the impression that you 
enjoy writing long posts :-)

Just one more stupid question: Are you talking about hardware-scanline 
renderers (OpenGL and the like) only or about REYES too? As far as I 
understand REYES is more related to scanline than raytracing and is in 
fact highly optimized to render huge amounts of primitives.

There are some test results and analysis about its time-complexity here: 
http://www.cis.ohio-state.edu/~stuart/cis781/final.html

[And again: I'm not trying to say that REYES is "better" than raytracing]

 > No, because the scanline algorithm requires you to draw everything in
 > the viewing area to determine its visibility.

I agree with you that raytracing would be the winner if there were *a 
lot* of primitives which appear smaller than a single pixel so that 
their bounding-boxes will never get hit by a ray - but usually both, 
REYES and game-engines use some sort of level-of-detail optimizations to 
prevent this scenario...

sascha

Thorsten Froehlich wrote:
> In article <3ee4e321$1@news.povray.org> , sascha 
> <sas### [at] userssourceforgenet>  wrote:
> 
> 
>>Then you explain how the raytracing algorithm could be optimized and
>>compare it again with the (unoptimized!) scanline algorithm. Hmmm...
> 
> 
> I knew somebody would ask, but answering it right along would have made a
> long post even longer :-)
> 
> No, the problem is, you cannot optimise the scanline algorithm further than
> what I outlined (at least not bringing down the complexity).  In fact, the
> complexity I outlined holds for the first implementations 30 or so years ago
> and it still holds in the 3d hardware accelerators of today.  The main
> benefit of the scanline algorithm is that you can make the constant time
> factor very, very small compared to ray-tracing.
> 
> 
>>But couldn't the same (or other - e.g. octree) optimizations be applied
>>to the scanline algorithm too?
> 
> 
> No, because the scanline algorithm requires you to draw everything in the
> viewing area to determine its visibility.  You can cull backfacing
> triangles, but that only divides to constant factor by about two.
> 
> 
>>Maybe I'm completely wrong, but doesn't your posting suggest that a
>>raytracer will always outperform a scanline-renderer if just the number
>>of objects is large enough?
> 
> 
> Yes, it does.  The problem is, the one million to one difference of the
> constant factors.  And due to the simplicity of the scanline algorithm, it
> is, compared to ray-tracing, much easier to implement it in hardware (you
> need only a few thousand gates, most of the logic on today's accelerator
> chips is used for texture and geometry computations.
> 
>     Thorsten
> 
> ____________________________________________________
> Thorsten Froehlich, Duisburg, Germany
> e-mail: tho### [at] trfde
> 
> Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message